home *** CD-ROM | disk | FTP | other *** search
/ Aminet 16 / Aminet 16 (1996)(GTI - Schatztruhe)[!][Dec 1996].iso / Aminet / dev / lang / uc_0_30.lha / u / rdocs / r0003.doc < prev    next >
Text File  |  1996-10-30  |  4KB  |  152 lines
  1. **********************
  2. * P R O J E C T  < U >
  3. *
  4. * Author and copyright
  5. * (c) 1996
  6. * Paul van der Valk
  7. *
  8. * file: r0003.doc
  9. * last updated: 30-oct-96
  10.  
  11.  
  12.  
  13.                   AN INTRODUCTION TO UCODE
  14.  
  15.  
  16. 1. The basic idea
  17. -----------------
  18.  
  19. The U-Project - short 'U' - is a programming environment built
  20. around a single universal code definition. This code definition
  21. is very strict. The tools that are built around this definition
  22. are however completely free-form - they can implement any subset
  23. of the original definition, in any desired implementation, on any
  24. platform.
  25.  
  26. The purpose of such universal code definition, named "UCode", 
  27. is to seperate the functionality of a given entity  (a program, 
  28. a subroutine, a dataset, ...) from it's actual implementation. 
  29.  
  30. In schematic form:
  31.  
  32.  
  33.                   --> implemantation 1
  34.                   |
  35.          UCode -----> implementation 2
  36.                   | 
  37.                   --> ................
  38.                   |
  39.                   --> implementation N
  40.  
  41.  
  42. There are many sorts of implementations possible. Consider:
  43.  
  44.    - A 68K code generator.
  45.  
  46.    - A PPC code generator.
  47.  
  48.    - A C code generator.
  49.  
  50.    - PASCAL code generator.
  51.  
  52.    - A whatever programming language code generator, with a
  53.      specific implementation flavour. For example, an abstract
  54.      GUI written in UCode could translate to an Amiga specific 
  55.      program (C/E/68k...) using MUI, BGUI, EAGUI, Triton, ...
  56.  
  57.    - A visualizer, presenting the program flow or module
  58.      layout (functions, datatypes, ...) in an ascii or a
  59.      graphical based display.
  60.  
  61.    - An anaylyzer/optimizer, checking for unused variables, 
  62.      multiple instances of constant (string) data, or 
  63.      code-fragments...
  64.  
  65.    - An executer, or interpreter if you prefer. The UCode
  66.      could be executed in whatever required environment. Text
  67.      output could be send to a console, or a dynamic HTML 
  68.      document in a browser.
  69.  
  70.    - A tracer/debugger.
  71.  
  72.    - ...
  73.  
  74. These backends are relatively easy to implement because the UCode is 
  75. defined in a binary format, based on linked records. A typcial UCode
  76. 'applications' consists of nested trees, which is quite usable for
  77. (source/object) code generation and analysis.
  78.  
  79.  
  80.  
  81. 2. Extending the concept
  82. ------------------------
  83.  
  84. Because human beings (normally :-)) don't deal with binary code,
  85. some sort of frontend is required to generate the UCode. There
  86. are a number of such frontends imaginable:
  87.  
  88.    - A procedural language of some sort, or possibly an existing 
  89.      language.
  90.  
  91.    - A higer level OO-ish language.
  92.  
  93.    - Binary data from say a paint-program (to be used as inline 
  94.      constant data).
  95.  
  96.    - A 'visual' UCode editor.
  97.  
  98.    - ...
  99.  
  100.  
  101. Since we already had several possible backend implementations, the 
  102. UCode falls in place between N frontends and M backends:
  103.  
  104.  
  105.  
  106.    frontend 1 --               --> backend 1
  107.                |               |
  108.    frontend 2 -----> UCode ------> backend 2
  109.                |               |
  110.    .......... --               --> .........
  111.                |               |
  112.    frontend N --               --> backend N
  113.  
  114.  
  115.  
  116. Obvious afvantages of such scheme are:
  117.  
  118.    - A high degree of portability.
  119.  
  120.    - Re-usable frontends/backends. For example, a good 68k generator
  121.      needs to be written only once. By providong a C and a PASCAL 
  122.      frontend,  you end up with a good C compiler and a good PASCAL 
  123.      compiler :)
  124.  
  125.    - A high abstraction level. Text/graphics code for example
  126.      has a strict defined behaviour, but an unknown actual
  127.      implementation. It's up to the backend...
  128.  
  129.    - A highly extendible environment.
  130.  
  131.  
  132.  
  133. Current and future state of the project
  134. ---------------------------------------
  135.  
  136. UCode implementations are currently available for AmigaOS only.
  137. Only one  beta-frontend (uca2b) and one beta-backend (umgk) are
  138. publicly available. A procedural language frontend (ucp2b) is
  139. under development. A 68k backend is under consideration, amongst
  140. other things.
  141.  
  142. UCode is open to implementation by anyone (please read r0002.doc;
  143. dislaimer and copyright). Since I don't have the time nor the
  144. knowledge to develop a wide range of front/backends, I encourage
  145. interested parties to develop their own implementations. You
  146. can mail me (address below) for related info.
  147.  
  148.  
  149. Paul van der Valk
  150. poing@luna.nl
  151.  
  152.